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DETAILED ACTION 

1 . This Action is in response to the Amendment for Application Number 1 0/601 ,237 
received on 6/14/2010. 

2. Claims 1-62 are presented for examination. 

Interference 

3. The request for interference filed 6/19/2003 is acknowledged. However, 
examination of this application has not been completed as required by 37 CFR 

41 .102(a). Consideration of a potential interference is premature. See MPEP § 2303. 

Claim Rejections - 35 USC §112 

The following is a quotation of the second paragraph of 35 U.S.C. 112: 

The specification sliall conclude witli one or more claims particularly pointing out and distinctly 
claiming the subject matter which the applicant regards as his invention. 

4. Claims 1-12, 14-25, 27-32, 41, 46, 53, 57 are rejected under 35 U.S.C. 112, 
second paragraph, as being indefinite for failing to particularly point out and distinctly 
claim the subject matter which applicant regards as the invention. 

5. Claims 1, 24, 53 recites the limitation, "associating an operation code with said 
first packet, wherein said operation code indicates a status of said first packet, including 
whether said packet is to be transferred to the host computer system for processing in 
accordance with said pres-selected protocol". Claim 1 then recites, "transferring said 
first packet to the host computer system for processing in accordance with said pre- 
selected protocol." It is unclear what the purpose is of determining whether to transfer 
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the packet to this host is for, when the next limitation always transfers the packet. It 
appears to defeat the entire purpose of the "determining step" when the following 
limitation always transfers the packet. 

6. Claim 24 as amended recites, "A method of transferring a packet to a host 
computer ". The last limitation of claim 24 recites, "transferhng said first packet to a host 
computer" , which appears to include insufficient antecedent basis. It is unclear as to 
whether this refers to the same host computer recited in the preamble, or another host 
computer. 

7. Claim 25 recites, "The method of claim 24, further comprising: transferring said 
TCB from said host computer system to said communication deyice." Howeyer, it 
appears in claim 24 that the TCB is generated at the communication deyice. 

Claim 24 

The first limitation recites, "parsing a header portion of a first packet receiyed at a 
communication deyice to determine if said first packet conforms to a pre-selected 
protocol". This limitation clearly recites the parsing being performed at the 
communication device. 

The second limitation recites, "generating a TCP control block (TCB) to identify a 
first communication flow that includes said first packet". This limitation clearly requires 
the possession of the packet in order to generate the TCB to identify the flow that 
includes said first packet . 
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The third limitation recites, "associating a summary with said first packet, wherein 
said summary indicates a status of said first packet, including whether said packet is to 
be transferred to the host computer system for processing". This limitation clearly 
shows that the packet has not yet been transferred to the host computer system, but 
rather indicates whether the packet should or should not be transferred to the host 
computer system. 

Therefore, the second limitation, (i.e. generating a TCB that identifies a flow 
including said first packet) must be performed at the communication device since the 
generation step clearly requires the use of the first packet, and the packet has not even 
been transferred to the host device at this point. 

However, claim 25 recites, "The method of claim 24, further comprising: 
transferring said TCB from said host computer system to said communication device." 
Therefore it is unclear how the TCB is transferred from the host computer system to the 
communication device if such is generated at the communication device. 

8. Claim 32 recites, "A method of transferring a packet received at a network 
interface to a host computer system". The amended limitation recites, "if the host 
computer system contains a plurality of processors such that a first of the processors is 
on the network interface". The preamble differentiates the network interface and the 
host computer system as two separate elements. Therefore it is unclear how one of the 
host computer system's processors can be on the network interface. 
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9. All dependent claims are also rejected herein as they include the limitations of 
their base claims. 

Claim Rejections - 35 USC § 103 

The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set 
forth in section 102 of this title, if the differences between the subject matter sought to be patented and 
the prior art are such that the subject matter as a whole would have been obvious at the time the 
invention was made to a person having ordinary skill in the art to which said subject matter pertains. 
Patentability shall not be negatived by the manner in which the invention was made. 

10. Claims 1-12, 14-17, 20-31, 42-44, 46-53, 55-56 are rejected under 35 U.S.C. 
103(a) as being unpatentable over Flanders et al. (US 6172980). 

1 1 . Regarding claims 1 , 24, 53, Flanders disclosed a method of transferring a packet 
to a computer system, wherein the packet is received at a communication device from a 
network (Flanders, col. 1, lines 39-41, a network router receiving and routing packets), 
comprising: 

parsing a header portion of a first packet received at a communication device to 
determine if said first packet conforms to a pre-selected protocol (Flanders, col. 3, lines 
60-65, "RHP (Receive Header Processor) determines the protocol being used for the 
received data unit"; See also col. 6, lines 50-51); 

generating a flow key to identify a first communication flow that includes said first 
packet (Flanders, col. 6, line 50 through col. 7, line 5, port information extracted from 
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the received frame in order to classify packet according to flow ID, the information 
extracted from the packet used as a flow key to look the packet up); 

routing the packets to their destination (Flanders, col. 1, lines 50-55, Flanders 
disclosed the router making forwarding decisions to route the packet, see also Abstract, 
"identifying a data unit to be routed by a router) 

associating an operation code with said first packet, wherein said operation code 
indicates a status of said first packet, including whether said packet is to be transferred 
to the hose computer system for processing in accordance with said pre=selected 
protocol (Flanders, col. 4, lines 22-35, 50-63 Flanders disclosed the RHP determining 
whether the packet is to be routed or bridged and performing protocol processing on the 
packet when it is to be routed based on bytes). 

Flanders further disclosed forwarding the packets for receipt by a downstream 
network device (Flanders, col. 9, lines 40-43). 

Flanders did not explicitly state transferring said first packet to the disclosed 
device system for processing in accordance with said pre-selected protocol. 

However, it would have been obvious to one of ordinary skill in the art at the time 
the invention was made that since the router of Flanders clearly routes the packet to a 
network device, that the network device must perform the proper protocol processing on 
the packet in order to properly interpret the information from that packet. For example, 
using the very well known TCP/IP protocol, in order for two computers to successfully 
communicate via TCP/IP (Flanders, Fig. 6), both computers must protocol process the 
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TCP/IP packets, which are clearly routed through the Internet, via routers such as the 
one described by Flanders. 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to interpret the routing of a packet to its destination to 
include that destination performing the proper protocol processing in order to obtain the 
predictable result of the destination device being able to successfully interpret that 
packet at the receiving end, thereby resulting in successful communication. 

Claim 24 includes a method with limitations that are substantially similar to the 
limitations of claim 1 , and is therefore rejected under the same rationale. Claim 53 
recites a computer readable storage medium storing instructions that perform the 
method of claim 1 . Therefore claims 24, 53 are rejected under the same rationale. 

12. Regarding claim 2, Flanders disclosed the limitations as described in claim 1 , 
including wherein said parsing comprises: copying a header portion of said first packet 
into a header memory; and examining said header portion according to a series of 
parsing instructions; wherein said parsing instructions are configured to reflect a set of 
pre-selected communication protocols (col. 3, lines 45-65). 

13. Regarding claim 3, Flanders disclosed the limitations as described in claim 2. 
Flanders did not explicitly wherein said parsing instructions are updateable. However, it 
would have been obvious to any programmer or designer at the time the invention was 
made that any instructions carried out by a machine are updateable, as any software or 
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hardware could be updated in order to accommodate the desires of the 
programmer/designer. 

14. Regarding claim 4, Flanders disclosed the limitations as described in claim 2, 
including copying a value from a field in a header of said header portion (Flanders, col. 
6, lines 50-56). 

15. Regarding claim 5, Flanders disclosed the limitations as described in claim 1 , 
including wherein said parsing comprises: extracting an identifier of a source of said first 
packet from said header portion; and extracting an identifier of a destination of said first 
packet from said header portion (Flanders, col. 3, lines 55-60). 

16. Regarding claim 6, Flanders disclosed the limitations as described in claim 5, 
including combining said source identifier and said destination identifier (Flanders, col. 
3, lines 55-60). 

17. Regarding claim 7, Flanders disclosed the limitations as described in claim 1 , 
including 

wherein said generating comprises retrieving an identifier of a communication 
connection from said header portion (Flanders, col. 6, lines 49-60). 
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18. Regarding claim 8, Flanders disclosed the limitations as described in claim 1, 
including storing said first packet in a packet memory prior to said transferring 
(Flanders, col. 3, lines 45-55). 

19. Regarding claim 9, Flanders disclosed the limitations as described in claim 1 , 
including storing said flow key in a flow database, wherein said flow database is 
configured to facilitate management of said first communication flow (Flanders, col. 6, 
lines 50-65, "Flow Filtering Table"). 

20. Regarding claim 10, Flanders disclosed the limitations as described in claim 9, 
including associating a flow number with said first packet, wherein said flow number 
comprises an index of said flow key within said flow database (Flanders, col. 6, lines 50- 
65, "Flow ID"). 

21 . Regarding claim 11, Flanders disclosed the limitations as described in claim 10, 
including storing said flow number in a flow memory (Flanders, col. 6, lines 50-65, "Flow 
ID" is stored in the table). 

22. Regarding claim 12, Flanders disclosed the limitations as described in claim 9, 
including updating an entry in said flow database associated with said flow key when a 
second packet in said first communication flow is received (Flanders, col. 6, line 65 
through col. 7, line 15). 
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23. Regarding claim 14, Flanders disclosed the limitations as described in claim 1 , 
including wherein said associating comprises: retrieving one or more header fields of 
said header portion; and analyzing said header fields to determine said status of said 
first packet (Flanders, col. 7, lines 1-15). 

24. Regarding claim 15, Flanders disclosed the limitations as described in claim 14, 
including wherein said analyzing comprises: determining whether said first packet 

includes a data portion; and if said first packet includes a data portion, determining 
whether said data portion exceeds a pre-determined size (Flanders, col. 4, lines 30-40). 

25. Regarding claim 16, Flanders disclosed the limitations as described in claim 14, 
including wherein said analyzing comprises determining whether said first packet was 
received out of order in said first communication flow (Flanders, Fig. 6, TCP which is 
enabled for out of order packets). 

26. Regarding claim 17, Flanders disclosed the limitations as described in claim 1, 
including storing said operation code in a control memory (Flanders, col. 7, lines 1-15). 

27. Regarding claim 20, Flanders disclosed the limitations as described in claim 1 , 
including determining whether a second packet received from said network is part of 
said first communication flow (col. 6, lines 50-65). 
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28. Regarding claim 21 , Flanders disclosed the limitations as described in claim 20, 
including maintaining a packet memory configured to store one or more packets 
received from said network (col. 3, lines 45-55); 

maintaining a flow memory configured to store, for each of said one or more packets, an 
identifier of a communication flow comprising said packet (col. 6, lines 50-65); and 
searching said flow memory for a first identifier of said first communication flow (col. 6, 
lines 50-65). 

29. Regarding claim 22, Flanders disclosed the limitations as described in claim 21 , 
including wherein said first identifier comprises said flow key (col. 6, lines 50-65). 

30. Regarding claim 23, Flanders disclosed the limitations as described in claim 21, 
including wherein said first identifier comprises a flow number of said first packet, 
wherein said flow number is an index of said flow key within a flow database (col. 6, 
lines 50-65). 

31 . Regarding claim 25, Flanders disclosed the limitations as described in claim 24, 
including transferring said TCB from said host computer system to said communication 
device (col. 6, lines 50-65). 
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32. Regarding claim 26, Flanders disclosed the limitations as described in claim 24, 
including receiving a second packet from a second communication flow; and processing 
said second packet by said communication device in accordance with said TCB (col. 6, 
lines 50-60, all packets received go through the same process if they are part of the 
same flow). 

33. Regarding claim 27, Flanders disclosed the limitations as described in claim 1 , 
including alerting said host computer system to the arrival of said first packet (col. 9, 
lines 40-45). 

34. Regarding claim 28, Flanders disclosed the limitations as described in claim 1 , 
including maintaining a packet memory configured to store packets received from said 
network (col. 3, lines 47-55). Flanders did not explicitly state randomly discarding a 
packet if said packet memory contains a pre-determined level of traffic. However, it 
would have been obvious to one of ordinary skill in the art at the time the invention was 
made that buffered packets would be discarded as new packets arrive at the buffer, 
especially during the case that the buffer is completely filled, i.e. the packet memory 
contains a predetermined traffic level, in order to make room for new arriving packets 
and to allow the router to continue to operate properly. 

35. Regarding claim 29, Flanders disclosed the limitations as described in claim 1 , 
including wherein said parsing includes determining, by hardware of the communication 



Application/Control Number: 1 0/601 ,237 Page 1 3 

Art Unit: 2443 

device, a protocol of tlie lieader (col. 3, lines 50-60). Flanders also clearly disclosed the 
teaching of multiple protocol support. 

The teachings of Flanders does not limit itself to any particular type of protocol. 
This would have motivated one of ordinary skill in the art to implement the teachings of 
Flanders with any protocol well known in the art. 

The session layer is a well known layer from the OSI model. Therefore it would 
have been obvious to one of ordinary skill in the art at the time the invention was made 
to incorporate the session protocol within the teachings of Flanders since in order to 
make the teaching of Flanders scalable across well known protocols, thereby increasing 
its customer's desirability of use. 

36. Regarding claim 30, Flanders disclosed the limitations as described in claim 1 , 

including wherein said generating a flow key includes initializing a communication 
control block (CCB) during Transport Control Protocol (TCP) connection setup (col. 7, 
lines 10-15). 

37. Regarding claim 31 , Flanders disclosed the limitations as described in claim 1 , 
including wherein said communication device is a network interface (Fig. 1). 

38. Regarding claims 42 and 44, Claim 42 includes an apparatus with a memory and 
modules to perform the limitations that are substantially similar to claim 1 and claim 44 
recites a computer system with limitations that are substantially to claims 1 . Claims 42 
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and 44 further includes a "flow re-assembler configured to re-assemble a data portion of 
said first packet with a data portion of second packet in said communication flow and 
storing both packets in memory as well as a processor to process said packet. As 
shown in the rejection of claim 1 , Flanders disclosed a router performing these 

limitations. 

Flanders did not explicitly state flow re-assembler configured to re-assemble a 
data portion of said first packet with a data portion of second packet in said 
communication flow and storing both packets in memory of the downstream network 
device. 

However, it would have been obvious to one of ordinary skill in the art at the time 
the invention was made that since the router of Flanders clearly routes the packets 
belonging to a particular flow to a network device, that the network device must perform 
the proper protocol processing on the packets in order to properly interpret the 
information from that packet, thereby requiring storing of the packet data and combining 
the data to properly interpret the flow. For example, using the very well known TCP/IP 
protocol, in order for two computers to successfully communicate via TCP/IP (Flanders, 
Fig. 6), both computers must protocol process the TCP/IP packets, which are clearly 
routed through the Internet, via routers such as the one described by Flanders. 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to interpret the routing of a packets to their destination to 
include that destination actually storing the packet data in order to perform the proper 
protocol processing in order to obtain the predictable result of the destination device 
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being able to successfully interpret/batch that data from the packets at the receiving 
end, thereby resulting in successful communication. For example, the routing of a file 
that requires multiple packets to be sent in order to transmit the entire file across the 
network, which requires the receiving end to properly protocol process the packets that 
make up the file and re-assemble the data portions in order for communication of the file 
to properly occur. 

39. Regarding claim 43, Flanders disclosed the limitations as described in claim 42, 
including wherein said traffic classifier comprises: a parser configured to parse a header 
portion of said first packet; a flow database configured to store a flow key identifying 
said communication flow; and a flow database manager configured to manage said flow 
database; wherein said flow key is generated from an identifier of a source of said first 
packet and an identifier of a destination of said first packet (Flanders, Flanders, col. 6, 
line 50 through col. 7, line 5, port information extracted from the received frame in order 
to classify packet according to flow ID, the information extracted from the packet used 
as a flow key to look the packet up, see also col. 1 , lines 50-61 ). 

40. Regarding claim 46, Flanders disclosed the limitations as described in claim 1 , 
wherein said operation code indicates whether the packet corresponds to Transport 
Control Protocol (TCP) (Flanders, col. 7, lines 10-15). 
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41 . Regarding claim 47, Flanders disclosed a device for receiving a packet from a 
network and transferring the packet to a host computer system, comprising: 

a parser configured to parse a header portion of a packet received from a 
network, wherein said parsing comprises: determining whether a header within said 
header portion conforms to one of a set of communication protocols (Flanders, col. 3, 
lines 60-65, "RHP (Receive Header Processor) determines the protocol being used for 
the received data unit"; See also col. 6, lines 50-51); and 

if said header conforms to one of said communication protocols, extracting information 
from said header portion to identify a communication flow to which said packet belongs 
(Flanders, col. 6, line 50 through col. 7, line 5, port information extracted from the 
received frame in order to classify packet according to flow ID, the information extracted 
from the packet used as a flow key to look the packet up); a flow memory configured to 
store a flow identifier for identifying said communication flow; a flow manager configured 
to assign an operation code to said packet, wherein said operation code: indicates a 
status of said packet; and indicates a manner of transferring said packet to the host 
computer system; a packet memory configured to store said packet (Flanders, col. 6, 
line 65 through col. 7, line 15, in accordance with the received frame, a status word is 
set; see also, col. 4, lines 15-23. Flanders further disclosed forwarding the packets for 
receipt by a downstream network device (Flanders, col. 9, lines 40-43). 

Flanders did not explicitly state transferring said first packet to the disclosed 
device system for processing in accordance with said pre-selected protocol. 
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However, it would have been obvious to one of ordinary skill in the art at the tinne the 
invention was made that since the router of Flanders clearly routes the packet to a 
network device, that the network device must perform the proper protocol processing on 
the packet in order to properly interpret the information from that packet. For example, 
using the very well known TCP/IP protocol, in order for two computers to successfully 
communicate via TCP/IP (Flanders, Fig. 6), both computers must protocol process the 
TCP/IP packets, which are clearly routed through the Internet, via routers such as the 
one described by Flanders. 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to interpret the routing of a packet to its destination to 
include that destination performing the proper protocol processing in order to obtain the 
predictable result of the destination device being able to successfully interpret that 
packet at the receiving end, thereby resulting in successful communication. 

Flanders also did not explicitly state wherein said device is coupled to the host 
computer system by a bus. However it well known to one of ordinary skill that a bus is a 
device that is used to connect various computers/devices in a network. Since the router 
and end node is connected by a network, it would have been obvious to one of ordinary 
skill in the art at the time the invention was made to couple these devices via a bus 
thereby making the system scalable towards already well known devices. 
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42. Regarding claim 48, Flanders disclosed the limitations as described in claim 47, 
wherein the device is a network interface (Flanders, Abstract). 

43. Regarding claim 49, Flanders disclosed the limitations as described in claim 47, 
said flow memory comprising a flow database configured to store a flow key, wherein 
said flow key is assembled from an identifier of a source of said packet and an identifier 
of a destination of said packet (Flanders, col. 6, line 50 through col. 7, line 5, port 
information extracted from the received frame in order to classify packet according to 
flow ID, the information extracted from the packet used as a flow key to look the packet 
up; col. 1, lines 50-67). 

44. Regarding claim 50, Flanders disclosed the limitations as described in claim 47, 
wherein said flow manager is further configured to update said flow memory as 
additional packets in said communication flow are received from the network (Flanders, 
col. 6, lines 50-67, col. 7, lines 1-5). 

45. Regarding claim 51 , Flanders disclosed the limitations as described in claim 47, 
said flow memory comprising a flow memory configured to store a flow number, wherein 
said flow number comprises an index of said communication flow in a flow database 
(Flanders, col. 6, lines 50-67, col. 7, lines 1-5). 
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46. Regarding claim 52, Flanders disclosed the limitations as described in claim 47, 
further comprising a control memory configured to store said operation code (Flanders, 
col. 7, lines 1-5). 

47. Regarding claim 55, Flanders disclosed the limitations as described in claim 47, 
wherein said transfer module is configured to transfer a data portion of said packet into 
one of a set of host memory areas in accordance with said operation code (Flanders, 
col. 7, lines 1-15). 

48. Regarding claim 56, Flanders disclosed the limitations as described in claim 47. 
Flanders did not explicitly state further comprising a packet batching module configured 
to determine whether said packet memory contains another packet in said 
communication flow. 

However, it would have been obvious to one of ordinary skill in the art at the time 
the invention was made that since the router of Flanders clearly routes the packets 
belonging to a particular flow to a network device, that the network device must perform 
the proper protocol processing on the packets in order to properly interpret the 
information from that packet, thereby requiring storing of the packet data and combining 
the data to properly interpret the flow. For example, using the very well known TCP/IP 
protocol, in order for two computers to successfully communicate via TCP/IP (Flanders, 
Fig. 6), both computers must protocol process the TCP/IP packets, which are clearly 
routed through the Internet, via routers such as the one described by Flanders. 
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Therefore, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to interpret the routing of a packets to their destination to 
include that destination actually storing the packet data in order to perform the proper 
protocol processing in order to obtain the predictable result of the destination device 
being able to successfully interpret/batch that data from the packets at the receiving 
end, thereby resulting in successful communication. For example, the routing of a file 
that requires multiple packets to be sent in order to transmit the entire file across the 
network, which requires the receiving end to properly protocol process the packets that 
make up the file and re-assemble the data portions in order for communication of the file 
to properly occur. 

49. Claim 18 is rejected under 35 U.S.C. 103(a) as being unpatentable over Flanders 
et al. (US 6172980) in view of Lincoln (US 5991265). 

50. Regarding claim 18, Flanders disclosed the limitations as described in claim 1 , 
including processing of the header at a Receive Header Processor (Flanders, col. 1, 

lines 50-60). 

Flanders did not explicitly state storing the data portion in a re-assembly storage 
area and one or more headers in a header storage area. 

In an analogous art of packet processing, Lincoln disclosed packet processing in 
which the system transfers the cell payloads to a reassembly memory while processing 
the headers from control memory and then combining the header and payload before 
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transferring the cell (Lincoln, col. 5, lines 30-40). As such, Lincoln provides evidence 
that it is well known to divide packets between header and payload in order to perform 
header processing of the packets. 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to utilize the splitting of packet header and payload as 
performed in the teachings of Lincoln in order to provide the system of Flanders in order 
to reduce the amount of data to be analyzed by the RHP in order to process the 
headers in a more efficient manner. 

51 . Claims 32, 45, 54 are rejected under 35 U.S.C. 103(a) as being unpatentable 
over Flanders et al. (US 6172980) in view of Seno et al. (US 5590328). 

52. Regarding claim 32, Flanders disclosed a method of transferring a packet 
received at a network interface to a host computer system, comprising: 

receiving a packet from a network, storing said packet in a packet memory and 
parsing a header portion of said packet; extracting a value stored in said header 
portion; identifying a communication flow comprising said packet (Flanders, col. 3, lines 
60-65, "RHP (Receive Header Processor) determines the protocol being used for the 
received data unit"; See also col. 6, lines 50-51; col. 6, line 50 through col. 7, line 5, port 
information extracted from the received frame in order to classify packet according to 
flow ID, the information extracted from the packet used as a flow key to look the packet 
up); 
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determining wlietlier a lieader in said header portion conforms to a pre-selected 
protocol (Flanders, col. 3, lines 60-65, "RHP (Receive Header Processor) determines 
the protocol being used for the received data unit"); 

determining whether a second pacl<et in said pacl<et memory is part of said 
communication flow (Flanders, col. 1, lines 39-40, Flanders disclosed performing the 
same for multiple received data units); and 

if the host computer system contains a plurality of processors such that a first 
processor of the processors is on the network interface and a second of the processors 
is on the host computer, identifying a processor of the first and second processors to 
process said packet (Flanders, col. 4, lines 22-35, 50-63 Flanders disclosed the RHP 
determining whether the packet is to be routed or bridged and performing protocol 
processing on the packet when it is to be routed based on bytes, therefore determining 
whether the interface processes the packet or if it is sent to the end device for 
processing). 

Flanders further disclosed forwarding the packets for receipt by a downstream 
network device (Flanders, col. 9, lines 40-43) 

Flanders did not explicitly state the step of storing said packet in a host memory 
area in the downstream network device. 

However, it would have been obvious to one of ordinary skill in the art at the time 
the invention was made that since the router of Flanders clearly routes the packet to a 
network device, that the network device must perform the proper protocol processing on 
the packet in order to properly interpret the information from that packet, thereby 
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requiring storing of the packet. For example, using the very well known TCP/IP 
protocol, in order for two computers to successfully communicate via TCP/IP (Flanders, 
Fig. 6), both computers must protocol process the TCP/IP packets, which are clearly 
routed through the Internet, via routers such as the one described by Flanders. 

Therefore, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to interpret the routing of a packet to its destination to 
include that destination actually storing the packet in order to perform the proper 
protocol processing in order to obtain the predictable result of the destination device 
being able to successfully interpret that packet at the receiving end, thereby resulting in 
successful communication. 



53. Regarding claim 45, Flanders disclosed the limitations as described in claim 42. 

Flanders also did not explicitly state wherein, comprising: a load distributor for 
identifying a first processor within the host computer system for processing said first 
packet and said second packet; wherein said load distributor identifies a second 
processor in the host computer system for processing a packet from a different 
communication flow. 
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In an analogous art, Seno disclosed a protocol parallel processing device in 
which the device determines which processor, among which of multiple processors, to 
process the packet according to the communication (Seno, col. 2, lines 35-65). 

One of ordinary skill in the art would have been motivated to combine the 
teachings of Flanders and Seno since both teachings involve protocol processing of 
packets, and as such, both are within the same environment. 

Therefore it would have been obvious to one of ordinary skill in the art to 
incorporate the "multiple processors" teaching as disclosed by Seno into the teachings 
of Flanders in order to distribute communications across multiple processors, thereby 
improving efficiency of routing data through the router as the load is distributed among 
multiple processors, while also increasing throughput (Seno, col. 2, lines 15-35). 

54. Regarding claim 54, Flanders disclosed the limitations as described in claim 47. 
Flanders did not explicitly state wherein said host computer system is a multi-processor 
host computer system, further comprising a load distributor configured to select one of 
said multiple processors for processing said packet in accordance with one of said 
communication protocols. 

In an analogous art, Seno disclosed a protocol parallel processing device in 
which the device determines which processor, among which of multiple processors, to 
process the packet according a protocol (Seno, col. 2, lines 35-65). 
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One of ordinary skill in the art would have been motivated to combine the 
teachings of Flanders and Seno since both teachings involve protocol processing of 
packets, and as such, both are within the same environment. 

Therefore it would have been obvious to one of ordinary skill in the art to 
incorporate the "multiple processors" teaching as disclosed by Seno into the teachings 
of Flanders in order to distribute communications across multiple processors, thereby 
improving efficiency of routing data through the router as the load is distributed among 
multiple processors, while also increasing throughput (Seno, col. 2, lines 15-35). 
Allowable Subject Matter 

55. Claims 13, 33-40, 58-62 allowed. 

56. Claims 1 9, 41 , 57 are objected to as being dependent upon a rejected base 
claim, but would be allowable if rewritten in independent form including all of the 
limitations of the base claim and any intervening claims. 

Response to Amendment 

Applicant's arguments and amendments filed on 6/14/2010 have been carefully 
considered but they are not deemed fully persuasive. 

In view of Applicant's arguments over the newly amended independent claims, 
Applicant is respectfully requested to review the 1 12 2"^ rejections, provided above. 

It is the Examiner's position that Applicant has not yet submitted claims drawn to 
limitations, which define the operation and apparatus of Applicant's disclosed invention 
in manner, which distinguishes over the prior art. 
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Failure for Applicant to significantly narrow definition/scope of the claims and 
supply arguments commensurate in scope with the claims implies the Applicant intends 
broad interpretation be given to the claims. The Examiner has interpreted the claims 
with scope parallel to the Applicant in the response and reiterates the need for the 
Applicant to more clearly and distinctly define the claimed invention. 



Conclusion 

Examiner's Note: Examiner has cited particular columns and line numbers in 
the references applied to the claims above for the convenience of the applicant. 
Although the specified citations are representative of the teachings of the art and are 
applied to specific limitations within the individual claim, other passages and figures 
may apply as well. It is respectfully requested from the applicant in preparing 
responses, to fully consider the references in entirety as potentially teaching all or part 
of the claimed invention, as well as the context of the passage as taught by the prior art 
or disclosed by the Examiner. 

In the case of amending the claimed invention, Applicant is respectfully 
requested to indicate the portion(s) of the specification which dictate(s) the structure 
relied on for proper interpretation and also to verify and ascertain the metes and bounds 
of the claimed invention. 

THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time 
policy as set forth in 37 CFR 1 .136(a). 
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A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within 
TWO MONTHS of the mailing date of this final action and the advisory action is not 
mailed until after the end of the THREE-MONTH shortened statutory period, then the 
shortened statutory period will expire on the date the advisory action is mailed, and any 
extension fee pursuant to 37 CFR 1 .136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later 
than SIX MONTHS from the mailing date of this final action. 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to J. Bret Dennison whose telephone number is (571) 272- 
3910. The examiner can normally be reached on M-F 8:30am-5pm. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Tonia Dollinger can be reached on (571) 272-4170. The fax phone number 
for the organization where this application or proceeding Is assigned is 571-273-8300. 

Information regarding the status of an application may be obtained from the 
Patent Application Information Retrieval (PAIR) system. Status information for 
published applications may be obtained from either Private PAIR or Public PAIR. 
Status information for unpublished applications is available through Private PAIR only. 
For more information about the PAIR system, see http://pair-direct.uspto.gov. Should 
you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). 
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Primary Examiner, Art Unit 2443 



